Maybe after the play button? Or is there a specific reason for putting it first?

Also, removing a container takes 15 seconds (so looks like the control hasn't worked), then the details panel breaks (but stays open).

Maybe after the play button? Or is there a specific reason for putting it first?

No reason, will do.

Also, removing a container takes 15 seconds (so looks like the control hasn't worked), then the details panel breaks (but stays open).

I have no intention of dealing with this in this PR, if thats alright.

Maybe after the play button? Or is there a specific reason for putting it first?

No reason, will do.

Actually, there sorted alphabetically. We can't control the order of them.

Also, removing a container takes 15 seconds (so looks like the control hasn't worked),

This will be fixed in #1363

then the details panel breaks (but stays open).

@davkal / @foot any ideas here? We leave the details panel open for good reason (reconnects etc), but perhaps you could close it if you receive a Remove node diff? But not if the ws goes away?

The details panel can handle 404s initially. Perhaps if it gets a 404 while waiting for a control to complete something bad happens. Will have a look.

Yes, we can close the details panel on node remove (we're already handling missing mouseout events that way). Otherwise we could do control update requests to get the status on a control action.

I propose this lifecycle-ish order: start - restart - pause - stop - remove

Could also be done in-band, in the control response. We just need to agree on a field. Eg. terminal controls return {pipe}, a remove control could return a different field. @tomwilkie

Sure, I can return a field saying along the lines of "deleteNode": "<nodeid>"?

Scratch that, lets be explicit. "closeDetails": true

I think thats all the feedback addressed - @paulbellamy PTAL?

I'm treating the removal in the UI only. closeOnSuccess is the UI's domain, the backend should not know about it.